The Resource Reservation Protocol (RSVP) is a network-control protocol that enables Internet applications to obtain differing qualities of service (QoS) for their data flows. Such a capability recognizes that different applications have different network performance requirements.
Some applications, including the more traditional interactive and batch applications, require reliable delivery of data but do not impose any stringent requirements for the timeliness of delivery. Newer application types, including videoconferencing, IP telephony, and other forms of multimedia communications require almost the exact opposite: Data delivery must be timely but not necessarily reliable. Thus, RSVP was intended to provide IP networks with the capability to support the divergent performance requirements of differing application types.
With the advent of network elements such as Session Border Controllers (SBC), RSVP is more easily used with rich services such as Voice over Internet Protocol (VoIP). Using SBCs, Internet technology professionals may now set up sessions that include both RSVP enabled and non-RSVP enabled devices. However, this approach is inefficient when multiple intermediary hops are used. The inefficiency may add significantly to the overhead of the communication. Additionally, there currently is no method to notify all elements in a given session of the presence or absence of RSVP in the flow.
Some current VoIP systems approach this problem by performing hop-by-hop negotiations during call setup, by tunneling RSVP between nodes, or by some hybrid of the two. In an example of a hop-by-hop negotiation, if there are two intermediate elements in the network (a-Int1-Int2-b), by the time the setup process reaches node b, the system will have set up two reservations prior to negotiating the bandwidth for the call. Instead, the reservations assume that the call with use a maximum bandwidth. That is, hop-to-hop negotiations only define the data path RSVP negotiations and do not take into account the application layer negotiations used to actually complete an end-to-end connection for transmission of the rich media over IP.
This technique is inefficient, since the reservations frequently need to be re-established to bring them in line with the actual utilization. Additionally, the reservation process is performed even when end-to-end reservation is required and some elements of the network do not support RSVP. Since RSVP cannot be used in such a situation, the reservation process wastes resources.
Like reference symbols in the various drawings indicate like elements.